The dissemination of dual-carrier cellular phones that have multiple communication bearers, such as WLAN and 3G, and the spread of fixed mobile convergence (FMC) services that are aimed at the integration of fixed-line and mobile telephones in recent years are expected to accompany an increase in the use of multiple IP telephony services, such as corporate and public networks, by a single user as disclosed in Japanese Laid-open Patent Publication No. 2004-328195. Such a case requires an IP telephone terminal of multi-vendor support that connects to multiple IP telephony services with a single telephone terminal.
For example, the use of session initiation protocol (SIP) as a call control protocol for IP telephony has become common, and sequences of basic services, such as terminal registration, conversation, call hold, and call transfer, have been implemented in much the same way due to standardization. However, supplementary services to be implemented (for example, call park, call pickup, setting and releasing of call forwarding, call queuing, and conference call) are not yet standardized and are, therefore, implemented in manners that are unique to each vendor.
This makes it difficult to develop a SIP stack that supports all of the supplementary services of respective vendors. To use the IP telephony services of multiple vendors with a single telephone terminal, an approach has been taken to individually develop SIP stacks that are specialized to the respective vendors and install the stacks in the terminal.
In the conventional art, the SIP stacks specialized to respective vendors are individually developed and installed in the telephone terminal, and therefore, the supplementary services of respective vendors are implemented by utilizing a wide variety of service sequences. Accordingly, the judgment for appropriately reporting call state transition varies depending on the service sequence.
More specifically, when carrying out basic services and supplementary services in an IP telephone terminal, a user interface (UI) requests the operation of a user, such as a request for supplementary services, from the SIP stack, and an SIP sequence executing unit of the SIP stack then sends and receives various SIP messages to execute the service sequence.
Furthermore, a significant change in state during the process of the service sequence is forwarded as a call state transition report to the UI, a higher-level module, and the UI makes a status report to the user to carry out various telephony services. The fact that the supplementary services of respective vendors are implemented by utilizing a wide variety of service sequences makes the judgment for appropriate reporting of call state transition different depending on the service sequence.
For example, there are two methods of SIP implementation to carry out call park as a supplementary service. One is to dial a second call to a special number using another signaling for control (control call) different from an existing call, and the other is to transfer an existing call to a special number for call park.
When developing a common SIP stack that can support these two types of implementations, in the method for dialing the second call to the special number, upon receiving a call establishment report for the second call, the UI (or the user thereof) needs to judge whether the report is of the call for “transfer” or the control call for “call park”. On the other hand, in the method for transferring to the special number for call park, when the completion of transfer is reported to the UI, the UI (or the user thereof) needs to judge whether the transfer completion report is a report of transfer completion based on the call park or a transfer completion report as a basic service.
Consequently, the fact that the criterion for an appropriate call state transition report varies depending on the sequence of respective supplementary services causes a problem in that SIP stacks are developed individually, resulting in an increase in development man-hours and extremely inefficient development of a terminal supporting multiple vendors.